home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-mimemhs-mapping-01.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
23KB
|
873 lines
draft MHS/RFC-822 Message Body Mapping Jun 92
Mapping between X.400 and RFC-822 Message Bodies
Thu Jun 25 19:32:19 1992
Harald Tveit Alvestrand
SINTEF DELAB
Harald.Alvestrand@delab.sintef.no
Steve Hardcastle-Kille
ISODE Consortium
S.Kille@isode.com
Robert S. Miles
Soft*Switch, Inc.
rsm@spyder.ssw.com
Marshall T. Rose
Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us
Steven J. Thompson
Soft*Switch, Inc.
sjt@gateway.ssw.com
Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 1]
draft MHS/RFC-822 Message Body Mapping Jun 92
Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
If consensus is reached in the IETF MIME-MHS Interworking
Working Group, it will be submitted to the IESG asking that it
be recommended to the IAB as a Proposed Standard protocol
specification.
Please send comments to the MIME-MHS mailing list:
<mime-mhs@surfnet.nl>
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 2]
draft MHS/RFC-822 Message Body Mapping Jun 92
1. Introduction
The Internet community is a large collection of networks under
autonomous administration, but sharing a core set of
protocols. These are known as the Internet suite of protocols
(or simply "TCP/IP").
Use of electronic-mail in the Internet is defined primarily by
one document, RFC-822[1], which defines the standard format
for the exchange of messages. RFC-822 has proven immensely
popular; in fact, the 822-connected Internet, is larger than
the scope of the IP-connected Internet.
The framework provided by RFC-822 allows for memo-based
textual messages. Each message consists of two parts: the
headers and the body. The headers are analogous to the
structured fields found in an inter-office memo, whilst the
body is free-form. Both parts are encoded using ASCII.
Recently, the Internet Engineering Task Force (IETF) has
developed an document called
Multipurpose Internet Mail Extensions
or MIME RFC-1341. The title is actually misleading. MIME
defines structure for Internet message bodies. It is not an
extension to RFC-822.
Independently of this, the International standards community
developed a different framework in 1984 (some say that's the
problem). This framework is known as the OSI Message Handling
System (MHS) or sometimes X.400.
Since the introduction of X.400(84), there has been work
ongoing for defining mappings between MHS and RFC-822. The
most recent work in this area is RFC-1327[3], which focuses
primarily on translation of envelope and headers. This
document is complimentary to RFC-1327 as it focuses on
translation of the message body. The mappings defined are
largely symmetrical with respect to MIME and MHS structuring
semantics, although the MIME semantics are somewhat richer.
In order to provide for reversible transformations, MHS
heading extensions are used to carry the additional MIME
semantics.
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 3]
draft MHS/RFC-822 Message Body Mapping Jun 92
2. Approach
The mappings have been specifically designed to provide
optimal behavior for three different scenarios:
(1) Allow a MIME user and an MHS user to exchange an
arbitrary binary content;
(2) Allow MIME content-types to "tunnel" through an MHS relay
(that is, two MIME users can exchange content-types
without loss through an MHS relay); and,
(3) Allow MHS body parts to "tunnel" through a MIME relay
(that is, two MHS users can exchange body parts without
loss through a MIME relay).
Other, related, scenarios can also be easily accommodated.
To facilitate the mapping process, the Internet Assigned
Numbers Authority (IANA) maintains a table termed the "IANA
MHS/MIME Equivalence Table". Once an enterprise has
registered an OID to describe an MHS body part, it should
complete a corresponding registry with the IANA for a MIME
content-type/subtype. In practice, the corresponding
content-type will be "application", with an appropriate choice
of sub-type and possible parameters. If a new MIME content-
type/subtype is registered with the IANA without a
corresponding entry in the Equivalence Table, the IANA will
assign it an OID, from the arc defined in this memo. See [4],
section 5 for details.
The companion document, "Equivalences between 1988 X.400 and
RFC-822 Message Bodies"[4], defines the initial configuration
of this table. The mappings described in both this document
and the companion document use the notational conventions of
RFC-1327.
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 4]
draft MHS/RFC-822 Message Body Mapping Jun 92
3. Mapping between X.400 and RFC-822 Message Bodies
MHS messages comprise of a heading and a body. The body is a
sequence of body parts. A body part may be a nested message.
A MIME message consists of headers and a content. For the
purpose of discussion, the content may be structured
(multipart or message), or atomic (otherwise). An element of
a structured content may be a message or a content. Both
message and structured content have subtypes which do not have
direct analogies in MHS.
The mapping between X.400 and RFC-822 message bodies which
this document defines is symmetrical for the following cases:
(1) any atomic body part
(2) multipart: digest and mixed subtypes
(3) message/rfc822
RFC-1327 specifies the mappings for headers. Section 5
describes how those mappings are modified by this document.
When mapping between an MHS body and a MIME content, the
following algorithm is used:
3.1. Mapping from X.400 to RFC-822
This section replaces the text in RFC-1327 starting at the
bottom of page 84,
The IPMS.Body is mapped into the RFC-822 message body.
Each IPMS.BodyPart is converted to ASCII as follows:
and continuing up to and including page 86 of Section 5.3.4 of
RFC-1327.
If the IPMS.Body
Body ::=
SEQUENCE OF
BodyPart
consists of a single body part, then the RFC-822 message body
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 5]
draft MHS/RFC-822 Message Body Mapping Jun 92
is constructed as the MIME content corresponding to that body
part.
If the body part is a forwarded IPMessage, the mapping is
applied recursively. Otherwise, to map a specific MHS body
part to a MIME content-type, the IANA MHS/MIME Equivalence
table is consulted. If the MHS body part is not identified in
this table, then the body-part is mapped onto an
"application/x400-bp" content, as specified in [4].
If the IPMS.Body consists of more than one body part, then the
RFC-822 message body is constructed as a
multipart/mixed
content-type, unless all of the body parts are messages, in
which case it is mapped to a
multipart/digest
content-type. Each component of the multipart content-type
corresponds to a IPMS.BodyPart, preserving the ordering of the
body parts in the IPMS.Body.
There is one case which gets special treatement. If the
IPMS.Body consists solely of a single IA5Text body part, then
the RFC822 message body is NOT marked as a MIME content. This
prevents RFC822 mailers from invoking MIME function
unnecessarily.
3.2. Mapping from RFC-822 to X.400
First, replace the first paragraph of Section 5.1.3 on page 72
of RFC-1327 to read as:
The IPM (IPMS Service Request) is generated according to
the rules of this section. The IPMS.body usually
consists of one IPMS.BodyPart of type
IPMS.IA5TextBodyPart
with
IPMS.IA5TextBodyPart.parameters.repertoire
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 6]
draft MHS/RFC-822 Message Body Mapping Jun 92
set to the default (ia5), which contains the body of the
RFC-822 message. However, if the 822.MIME-Version header
field is present, a special algorithm is used to generate
the IPMS.body.
Second, replace the "Comments:" paragraph on page 74 to reads
as:
Comments:
If an 822.MIME-Version header field is not present,
generate an IPMS.Bodypart of type
IPMS.IA5TextBodyPart
with
IPMS.IA5TextBodyPart.parameters.repertoire
set to the default (ia5), containing the value of
the fields, preceded by the string "Comments: ".
This body part shall preceed the other one.
Third, add the remainder of this section to the end of Section
5.1.3 of RFC-1327.
If the 822.MIME-Version header field is present, the following
mapping rules are used to generate the IPMS.body.
If the MIME content-type is one of:
(1) any atomic body part
(2) multipart: digest and mixed subtypes
(3) message/rfc822
then the symmetric mapping applies as described in Section
4.1.
Otherwise, three cases remain, which are discussed in turn.
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 7]
draft MHS/RFC-822 Message Body Mapping Jun 92
3.2.1. Mappings from the Message Content Type
3.2.1.1. Message/External-Body
This is mapped into a mime-body-part, as specified in [4].
3.2.1.2. Message/Partial
This is mapped onto a message, and the following heading
extension is used. The extension is derived from the
message/partial parameters:
partial-message HEADING-EXTENSION
VALUE PartialMessage
::= id-hex-partial-message
PartialMessage ::=
SEQUENCE {
number INTEGER,
total INTEGER,
id IA5String
}
If this heading is present when mapping from MHS to MIME, then
a message/partial should be generated.
3.2.2. Mappings from the Multipart Content-type
In MIME, a multipart content, refers to a set of content-
types, not a message with a set of content-types. However,
the multipart content will always be mapped to an MHS message.
The only mandatory field in the heading is the IPM.this-IPM,
which must always be generated (by the gateway). A
IPM.subject field should also be generated where there is no
"real" heading. This will present useful information to the
non-MIME capable X.400(88) and to all X.400(84) UAs.
The following heading extension should be generated, with the
enumerated value set according to the subtype:
multipart-message HEADING-EXTENSION
VALUE MultipartType
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 8]
draft MHS/RFC-822 Message Body Mapping Jun 92
::= id-hex-multipart-message
MultipartType ::=
ENUMERATED {
mixed(1),
alternative(2),
digest(3),
parallel(4)
}
The IPM.subject fields for the various types are:
mixed: "Multipart Message"
alternative: "Alternate Body Parts containing the same information"
digest: "Message Digest"
parallel: "Body Parts to be interpreted in parallel"
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 9]
draft MHS/RFC-822 Message Body Mapping Jun 92
4. Mapping between X.400 and RFC-822 Message Headers
Replace the first paragraph of Section 3.3.4 on page 26 of
RFC-1327 to read as:
In cases where T.61 strings are used only for conveying
human-interpreted information, the aim of this mapping is
to render the characters appropriately in the remote
character set, rather than to maximize reversibility.
For these cases, the following steps are followed to find
an appropriate encoding:
1) If all the characters in the string are contained
within the ASCII repertoire, the string is simply copied.
2) If all the characters in the string are from an IANA-
registered character set, then the appropriate encoded-
word(s) according to [5] are generated instead.
3) If the characters in the string are from a character
set which is not registered with the IANA, then the
mappings to IA5 defined in CCITT Recommendation X.408
(1988) shall be used [CCITT/ISO88a]. These will then be
encoded in ASCII.
This approach will only be used for human-readable
information (Subject and FreeForm Name).
When mapping from an RFC-822 header, when an encoded-word
(as defined in [5]) is encountered:
1) If all the characters contained therein are mappable
to T.61, the string content shall be converted into T.61.
2) Otherwise, the encoded-word shall be copied directly
into the T.61 string.
Modify procedure "2a" on page 56 of RFC-1327 to read as:
If the IPMS.ORDescriptor.free-form-name is present,
convert it to ASCII or T.61 (Section 3.3.4), and use this
as the 822.phrase component of the 822.mailbox construct.
Modify the final paragraph of procedure "2" on page 55 of
RFC-1327 to read as:
The string is then encoded into T.61 or ASCII using a
human-oriented mapping (as described in Section 3.3.4).
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 10]
draft MHS/RFC-822 Message Body Mapping Jun 92
If the string is not null, it is assigned to
IPMS.ORDescriptor.free-form.name.
Modify the second paragraph of procedure "3" on page 55 of
RFC-1327 to read as:
If the 822.group construct is present, any included
822.mailbox is encoded as above to generate a separate
IPMS.ORDescriptor. The 822.group is mapped to T.61 or
ASCII (as described in Section 3.3.4), and an
IPMS.ORDescriptor with only an free-form-name component
is built from it.
Modify procedure "822.Subject" on page 62 of RFC-1327 to read
as:
Mapped to IMPS.Heading.subject. The field-body uses the
human-oriented mapping referenceed in Section 3.3.4.
Modify procedure "IPMS.Heading.subject" on page 71 of RFC-1327
to read as:
Mapped to "Subject:". The contents are converted to
ASCII or T.61 (Section 3.3.4). Any CRLF are not mapped,
but are used as points at which the subject field must be
folded.
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 11]
draft MHS/RFC-822 Message Body Mapping Jun 92
5. OID Assignments
MIME-MHS DEFINITIONS ::= BEGIN
EXPORTS -- everything --;
IMPORTS
experimental
FROM RFC1155-SMI;
-- this assignment will change if this document --
-- is issued as a standards-track RFC --
mime-mhs OBJECT IDENTIFIER ::= { experimental 34 }
mime-mhs-headings OBJECT IDENTIFIER ::= { mime-mhs 1 }
id-hex-partial-message OBJECT IDENTIFIER ::=
{ mime-mhs-headings 1 }
id-hex-multipart-message OBJECT IDENTIFIER ::=
{ mime-mhs-headings 2 }
mime-mhs-bodies OBJECT IDENTIFIER ::= { mime-mhs 2 }
END
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 12]
draft MHS/RFC-822 Message Body Mapping Jun 92
6. Security Considerations
There are no explicit security provisions in this document.
However, a warning is in order. This document maps two
mechanisms between RFC822 and X.400 that could cause problems.
The first is the transfer of binary files. The inherent risks
are well known and won't be reiterated here. The second is
the propagation of strong content typing. The typing can be
used to automatically "launch" or initiate applications
against those contents. Any such launching leaves the invoker
vulnerable to application-specific viruses; for example, a
spreadsheet macro or Postscript command that deletes files.
See [2], Section 7.4.2 for a Postscript-specific discussion of
this issue.
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 13]
draft MHS/RFC-822 Message Body Mapping Jun 92
7. References
[1] D.H. Crocker, Standard for the Format of ARPA Internet
Text Messages. Request for Comments 822, (August, 1982).
[2] N. Borenstein, N. Freed, MIME: Mechanisms for Specifying
and Describing the Format of Internet Message Bodies.
Request for Comments 1341, (June, 1992).
[3] S.E. Hardcastle-Kille, Mapping between X.400(1988) / ISO
10021 and RFC-822. Request for Comments 1327, (May,
1992).
[4] H.T. Alvestrand, S.J. Thompson, Equivalences between 1988
X.400 and RFC-822 Message Bodies. Internet-Draft, (June,
1992).
[5] K. Moore. Representation of Non-ASCII Text in Interenet
Message Headers. Message Bodies. Request for Comments
1342, (June, 1992).
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 14]
draft MHS/RFC-822 Message Body Mapping Jun 92
Table of Contents
Status of this Memo .................................... 1
1 Introduction .......................................... 3
2 Approach .............................................. 4
3 Mapping between X.400 and RFC-822 Message Bodies ...... 5
3.1 Mapping from X.400 to RFC-822 ....................... 5
3.2 Mapping from RFC-822 to X.400 ....................... 6
3.2.1 Mappings from the Message Content Type ............ 8
3.2.1.1 Message/External-Body ........................... 8
3.2.1.2 Message/Partial ................................. 8
3.2.2 Mappings from the Multipart Content-type .......... 8
4 Mapping between X.400 and RFC-822 Message Headers ..... 10
5 OID Assignments ....................................... 12
6 Security Considerations ............................... 13
7 References ............................................ 14
Alvestrand, Kille, Miles, Rose, Thompson Exp Dec 92 [Page 15]